home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 19 / CU Amiga Magazine's Super CD-ROM 19 (1998)(EMAP Images)(GB)[!][issue 1998-02].iso / CUCD / Online / RFCs / rfc / rfc2171.txt < prev    next >
Text File  |  1997-06-23  |  17KB  |  508 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       K. Murakami
  8. Request for Comments: 2171                                  M. Maruyama
  9. Category: Informational                                NTT Laboratories
  10.                                                               June 1997
  11.  
  12.        MAPOS - Multiple Access Protocol over SONET/SDH  Version 1
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Authors' Note
  21.  
  22.    This memo documents a multiple access protocol for transmission of
  23.    network-protocol datagrams, encapsulated in High-Level Data Link
  24.    Control (HDLC) frames, over SONET/SDH.  This document is NOT the
  25.    product of an IETF working group nor is it a standards track
  26.    document.  It has not necessarily benefited from the widespread and
  27.    in depth community review that standards track documents receive.
  28.  
  29. Abstract
  30.  
  31.    This document describes the protocol MAPOS, Multiple Access Protocol
  32.    over SONET/SDH, for transmitting network-protocol datagrams over
  33.    SONET/SDH.  It focuses on the core protocol -- other documents listed
  34.    in the bibliography may be referenced in conjunction with this
  35.    document to provide support and services for protocols at higher
  36.    layers.
  37.  
  38. 1. Introduction
  39.  
  40. 1.1 SONET/SDH
  41.  
  42.    The Synchronous Optical Network/Synchronous Digital Hierarchy
  43.    (SONET/SDH) [1][2][3][4] family of ITU-T standard protocols are
  44.    designed to provide common, simple, and flexible interface for
  45.    broadband optical fiber transmission systems.  It enables direct
  46.    octet-synchronous multiplexing of lower rate tributaries.
  47.    SONET/SDH-compliant transmission systems are widely deployed by
  48.    telephone carriers world wide.
  49.  
  50.    This document defines the MAPOS protocol -- a method for transmitting
  51.    HDLC frames over SONET/SDH. The protocol provides multiple access
  52.    capability to SONET/SDH, an inherently point-to-point link. This
  53.    enables construction of seamless networking environment using
  54.    SONET/SDH as transmission media for both LAN and WAN.
  55.  
  56.  
  57.  
  58. Murakami & Maruyama          Informational                      [Page 1]
  59.  
  60. RFC 2171                         MAPOS                         June 1997
  61.  
  62.  
  63. 1.2 Possible Configurations
  64.  
  65.    The MAPOS protocol provides multiple access, broadcast / multicast-
  66.    capable switched LAN environment using SONET/SDH lines as
  67.    transmission media.  Possible configurations of MAPOS system are
  68.    shown in the following diagrams.  In (a), two end nodes are connected
  69.    to each other.  Figure (b) shows a star-topology "SONET-LAN" where
  70.    multiple end nodes are connected to an HDLC frame switch. The frame
  71.    switch forwards packets between nodes and provides multiple access
  72.    capability. In (c), multiple frame switches are linked together,
  73.    creating a switching cluster.
  74.  
  75.  
  76.            +------+                                +------+
  77.            | Node +--------------------------------+ Node |
  78.            +------+                                +------+
  79.  
  80.                     (a) Point-to-Point configuration
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Murakami & Maruyama          Informational                      [Page 2]
  115.  
  116. RFC 2171                         MAPOS                         June 1997
  117.  
  118.  
  119.            +------+                                +---------------+
  120.            | Node +--------------------------------+               |
  121.            +------+                                |               |
  122.                                                    |               |
  123.            +------+                                |               |
  124.            | Node +--------------------------------+               |
  125.            +------+                                |               |
  126.                                                    | Frame Switch  |
  127.            +------+                                |               |
  128.            | Node +--------------------------------+               |
  129.            +------+                                |               |
  130.                                                    |               |
  131.            +------+                                |               |
  132.            | Node +--------------------------------+               |
  133.            +------+                                +---------------+
  134.  
  135.                  (b) Point-to-Multipoint configuration
  136.  
  137.  
  138.            +--------+                      +--------+
  139.            | Frame  +----------------------+ Frame  |
  140.            | Switch +--------+    +--------+ Switch |
  141.            +--+-----+      +-+----+-+      +--------+
  142.               |            | Frame  |                      +--------+
  143.            +--+-----+      | Switch |      +--------+      | Frame  |
  144.            | Frame  |      +-----+--+      | Frame  +------+ Switch |
  145.            | Switch |            +---------+ Switch |      ++-------+
  146.            +-------++                      +--------+       |
  147.                    |________________________________________|
  148.  
  149.                   (c) Switching cluster configuration
  150.  
  151.                    Figure 1. Possible configurations
  152.  
  153.    Each port on a switch has an unique identifier within the switch. A
  154.    node connected to a switch port must inherit the address of the port.
  155.    That is, the node address is equal to the port identifier and is
  156.    unique within the switch.
  157.  
  158.    In a switch cluster, a node address is subnetted. The high-order
  159.    bits, the part where the corresponding bits in the "subnet mask" are
  160.    1, indicate the switch address.  The remaining low-order bits
  161.    indicate the unique node address within the switch. The two fields
  162.    form an unique address for a given node.
  163.  
  164.    In either case, the address may be configured manually into a node
  165.    interface, or automatically by the address assignment mechanism
  166.    described in [5].
  167.  
  168.  
  169.  
  170. Murakami & Maruyama          Informational                      [Page 3]
  171.  
  172. RFC 2171                         MAPOS                         June 1997
  173.  
  174.  
  175.    Note that any two components may be connected either directly, or via
  176.    a long-haul SONET/SDH leased line.
  177.  
  178. 1.3 Packet Transmission
  179.  
  180.    The protocol is connection-less -- when a node wish to communicate
  181.    with some other node, it simply fills-in the destination address of
  182.    an HDLC frame, places it in one or more SONET/SDH payloads, and sends
  183.    it over a SONET/SDH link.
  184.  
  185.    The switch forwards the frame to its destination based on the
  186.    destination address. In a switch cluster, the frame may be forwarded
  187.    by multiple switches and is eventually delivered to the specified
  188.    node.  Broadcast and multicast are also supported. Frames with an
  189.    invalid destination address are silently discarded.
  190.  
  191.    Like ethernet, the multiple access capability is provided by a switch
  192.    or a switch cluster. Since MAPOS is a link layer protocol, it is
  193.    independent of the upper layer protocols. That is, it can support any
  194.    network layer protocols such as IP. MAPOS IPv4 support is described
  195.    in [6].
  196.  
  197. 2. Physical Layer
  198.  
  199.    This protocol treats the underlying end-to-end SONET/SDH transmission
  200.    link as if it was a plain, transparent channel.  It sends HDLC frames
  201.    in SONET/SDH payloads, and expects them to arrive at the other end
  202.    unaltered.
  203.  
  204.    Each node and switch should terminate SONET/SDH overhead such as
  205.    section overhead, line overhead, and path overhead according to the
  206.    specification of SONET/SDH. Unfortunately, SONET and SDH overhead
  207.    interpretations are not identical. In addition, some SONET/SDH
  208.    implementations utilize some overhead bytes in proprietary manner.
  209.  
  210.    The detail of the interpretation is beyond the scope of this
  211.    document.  Appendix A describes some of the most significant
  212.    differences among SONET, SDH, and their implementations that often
  213.    causes interoperability problems.  Implementors of SONET/SDH
  214.    interfaces are strongly encouraged to be aware of such differences,
  215.    and provide workaround options in their products.
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Murakami & Maruyama          Informational                      [Page 4]
  227.  
  228. RFC 2171                         MAPOS                         June 1997
  229.  
  230.  
  231. 3. Data Link Layer
  232.  
  233. 3.1 HDLC Frame Format
  234.  
  235.    MAPOS uses the same HDLC-like framing as used in PPP-over-SONET,
  236.    described in RFC-1662[7].  Figure 2 shows the frame format.  Logical
  237.    Link Control (LLC), and Sublayer/Sub-Network Access Protocol (SNAP)
  238.    are not used.  It does not include the bytes for transparency.  The
  239.    fields are transmitted from left to right.
  240.  
  241.            +----------+----------+----------+----------+
  242.            |          |          |          |          |
  243.            |   Flag   | Address  | Control  | Protocol |
  244.            | 01111110 |  8bits   | 00000011 |  16 bits |
  245.            +----------+----------+----------+----------+
  246.               +-------------+------------+----------+-----------
  247.               |             |            |          | Inter-frame
  248.               | Information |    FCS     |   Flag   | fill or next
  249.               |             | 16/32 bits | 01111110 | address
  250.               +-------------+------------+----------+------------
  251.  
  252.                         Figure 2.  Frame format
  253.  
  254.      Flag Sequence
  255.  
  256.      Flag sequence is used for frame synchronization.  Each frame begins
  257.      and ends with a flag sequence 01111110 (0x7E).  If a frame
  258.      immediately follows another, one flag sequence may be treated as
  259.      the end of the preceding frame and the beginning of the immediately
  260.      following frame.  When the line is idle, the flag sequence is to be
  261.      transmitted continuously on the line.
  262.  
  263.      Address
  264.  
  265.      The address field contains the destination HDLC address.  A frame
  266.      is forwarded by a switch based on this field.  It is 8 bits wide.
  267.      The LSB indicates the end of this field, and must always be 1.  The
  268.      MSB is used to indicate if the frame is a unicast or a multicast
  269.      frame.  The MSB of 0 means unicast, with the remaining six bits
  270.      indicating the destination node address. MSB of 1 means multicast,
  271.      with the remaining six bits indicating the group address.  The
  272.      address 11111111 (0xFF) means that the frame is a broadcast frame.
  273.      The address 00000001 (0x01) is reserved to identify the control
  274.      processor inside a switch.  Frames with an invalid address should
  275.      be silently discarded.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Murakami & Maruyama          Informational                      [Page 5]
  283.  
  284. RFC 2171                         MAPOS                         June 1997
  285.  
  286.  
  287.              +-------------+-+
  288.              | | | | | | | | |
  289.              | | node addr |1|
  290.              +-+-----------+-+
  291.               ^             ^
  292.               |             |
  293.               |             +------- EA bit (always 1)
  294.               |
  295.               1 : broadcast, multicast
  296.               0 : unicast
  297.  
  298.                         Figure 3 Address format
  299.  
  300.      Control
  301.  
  302.      The control field contains single octet 00000011 (0x03) which, in
  303.      HDLC nomenclature, means that the frame is an Unnumbered
  304.      Information (UI) with the Poll/Final (P/F) bit set to zero.  Frames
  305.      with any other control field values should be silently discarded.
  306.  
  307.      Protocol
  308.  
  309.      The protocol field indicates the protocol to which the datagram
  310.      encapsulated in the information field belongs.  It conforms to the
  311.      ISO 3309 extension mechanism, and the value for this field may be
  312.      obtained from the most recent "Assigned Numbers" [8] and "MAPOS
  313.      Version 1 Assigned Numbers" [9].
  314.  
  315.      Information
  316.  
  317.      The information field contains the datagram for the protocol
  318.      specified in the protocol field.  The length of this field may
  319.      vary, but shall not exceed 65,280 (64K - 256) octets.
  320.  
  321.      Frame Check Sequence (FCS)
  322.  
  323.      By default, the frame check sequence (FCS) field is 16-bits long.
  324.      Optionally, 32 bit FCS may be used instead.  The FCS is calculated
  325.      over all bits of the address, control, protocol, and information
  326.      fields prior to escape conversions.  The least significant octet of
  327.      the result is transmitted first as it contains the coefficient of
  328.      the highest term.
  329.  
  330.      Inter-frame fill
  331.  
  332.      A sending station must continuously transmit the flag sequence as
  333.      inter-frame fill after the FCS field.  The inter-frame flag
  334.      sequences must be silently discarded by the receiving station.
  335.  
  336.  
  337.  
  338. Murakami & Maruyama          Informational                      [Page 6]
  339.  
  340. RFC 2171                         MAPOS                         June 1997
  341.  
  342.  
  343.      When an under-run occurs during DMA in the sending station, it must
  344.      abort the frame transfer and continuously send the flag sequence to
  345.      indicate the error.
  346.  
  347. 3.2 Octet-Synchronous Framing
  348.  
  349.    MAPOS uses an octet stuffing procedure because it treats SONET/SDH as
  350.    a byte-oriented synchronous link.  Since SONET/SDH provides
  351.    transparency, Async-Control-Character-Map (ACCM) is not used.  HDLC
  352.    frames are mapped into the SONET/SDH payload as follows.
  353.  
  354.    Each HDLC frame is separated from another frame by one or more flag
  355.    sequence, 01111110 (0x7E).  An escape sequence is defined to escape
  356.    the flag sequence and itself.  Prior to sending the frame, but after
  357.    the FCS computation, every occurrence of 01111110 (0x7E) other than
  358.    the flags is to be converted to the sequence 01111101 01011110 (0x7D
  359.    0x5E), and the sequence 01111101 (0x7D) is to be converted to the
  360.    sequence 01111101 01011101 (0x7D 0x5D).  Upon receiving a frame, this
  361.    conversion must be reversed prior to FCS computation.
  362.  
  363. 4. Further Reading
  364.  
  365.    To fully utilize MAPOS protocol, it is useful to reference other
  366.    documents[5][6][9][10] in conjunction with this document.
  367.  
  368. 5. Security Considerations
  369.  
  370.    Security issues are not discussed in this memo.
  371.  
  372. References
  373.  
  374.    [1]  CCITT Recommendation G.707: Synchronous Digital Hierarchy Bit
  375.         Rates (1990).
  376.  
  377.    [2]  CCITT Recommendation G.708: Network Node Interface for
  378.         Synchronous Digital Hierarchy (1990).
  379.  
  380.    [3]  CCITT Recommendation G.709: Synchronous Multiplexing Structure
  381.         (1990).
  382.  
  383.    [4]  American National Standard for Telecommunications - Digital
  384.         Hierarchy - Optical Interface Rates and Formats Specification,
  385.         ANSI T1.105-1991.
  386.  
  387.    [5]  Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension -
  388.         Node Switch Protocol," RFC2173, June, 1997.
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Murakami & Maruyama          Informational                      [Page 7]
  395.  
  396. RFC 2171                         MAPOS                         June 1997
  397.  
  398.  
  399.    [6]  Murakami, K. and M. Maruyama, "IPv4 over MAPOS Version 1,"
  400.         RFC2176, June, 1997.
  401.  
  402.    [7]  Simpson, W., editor, "PPP in HDLC-like Framing," RFC1662, July
  403.         1994.
  404.  
  405.    [8]  IANA, "IANA-Assignments,"
  406.         http://www.iana.org/iana/assignments.html
  407.  
  408.    [9]  Maruyama, M. and K. Murakami, "MAPOS Version 1 Assigned
  409.         Numbers," RFC2172, June 1997.
  410.  
  411.    [10] Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension -
  412.         Switch Switch Protocol," RFC2174, June, 1997.
  413.  
  414. Acknowledgements
  415.  
  416.    The authors would like to acknowledge the contributions and
  417.    thoughtful suggestions of John P. Mullaney, Clark Bremer, Masayuki
  418.    Kobayashi, Paul Francis, Toshiaki Yoshida, and Takahiro Sajima.
  419.  
  420. Author's Address
  421.  
  422.              Ken Murakami
  423.              NTT Software Laboratories
  424.              3-9-11, Midori-cho
  425.              Musashino-shi
  426.              Tokyo-180, Japan
  427.              E-mail: murakami@ntt-20.ecl.net
  428.  
  429.              Mitsuru Maruyama
  430.              NTT Software Laboratories
  431.              3-9-11, Midori-cho
  432.              Musashino-shi
  433.              Tokyo-180, Japan
  434.              E-mail: mitsuru@ntt-20.ecl.net
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Murakami & Maruyama          Informational                      [Page 8]
  451.  
  452. RFC 2171                         MAPOS                         June 1997
  453.  
  454.  
  455. APPENDIX A.  Differences among SONET, SDH, and their Implementations
  456.  
  457.    This section briefly describes the major differences among SONET
  458.    which is an ANSI standard, SDH, an ITU-T standard, and their
  459.    implementations.
  460.  
  461.      AU pointer (H1, H2, H3)
  462.  
  463.      The AU pointer consists of bytes H1, H2, and H3. The bits 5 and 6
  464.      of the H1 byte are called "SS bits," and are used to indicate the
  465.      offset into the payload where the beginning of a SPE is located.
  466.      (Note that "SPE" is a SONET term -- SDH calls it "VC.")  In the
  467.      case of OC-3c, SONET sets the SS bits of the second and the third
  468.      H1 bytes to 0, whereas SDH sets them to 10 for AU-4, and 01 for
  469.      AU-31.  Although the SS bits may be ignored at the receiving
  470.      station, some transmission systems discards SONET/SDH frames with
  471.      SS bits that it doesn't expect -- the sending station should be
  472.      aware of this, and include a configuration option to handle it.
  473.  
  474.      Z1 and Z2
  475.  
  476.      The Z bytes are reserved in SONET/SDH.  Some transmission systems,
  477.      however, use them in a proprietary manner.  SONET uses Z1 for Line
  478.      Error Monitoring.  NTT, a carrier in Japan, utilized Z1 for
  479.      Automatic Protection Switching (APS.)
  480.  
  481.      DCC Bytes
  482.  
  483.      The D bytes are called the Data Communication channel (DCC), and
  484.      are defined for maintenance and operations.  However, some carriers
  485.      and vendors use them in a proprietary manner.  For example, NTT's
  486.      STM-1 UNI uses the D4, D5, and D6 bytes to transfer section and
  487.      path maintenance information.
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Murakami & Maruyama          Informational                      [Page 9]
  507.  
  508.